從 Render Duration 到 Framework Attribution，如何判斷效能改善來自哪一層？

Day 18 做完 VDOM Stress Test 的初步觀察後，我們知道 大量 UI Rendering 的成本，會隨 Node Count 改變，而且不同階段的主要成本並不相同。

Mount 隨規模增加，Rendering / Layout 的比例逐漸提高；Update 則隨 Node Count 增加，Scripting 逐漸成為主要成本。

今天開始做正式的 Vue 3.5.40 vs Vue 3.6.0-rc.2 Validation，如果 Vue 3.6 的 Render Duration 變短了，這個改善到底發生在哪一層？

先把實驗條件固定下來

這次正式 Validation 使用相同 Scenario、相同 Node Count、相同測量流程，只切換 Vue 版本。

完整 matrix：

2 Vue versions
× 4 Node Counts
× 2 Operations
× 10 measurements
× 2 trace sources

= 160 measurement trials
= 320 trigger + trace cycles

每一次測量同時留下：

Scenario
 └─ Render Duration

Cost Trace
 ├─ Scripting
 ├─ Rendering
 ├─ Recalculate Style
 ├─ Layout
 ├─ Painting
 └─ Paint

Runtime Attribution
 ├─ Vue Runtime
 ├─ Application
 └─ V8 / native

這裡開始，Render Duration 只是入口，不再是最後答案。

為什麼不能只看 Render Duration？

只看 Render Duration 直覺很容易得到 Vue 3.6 快或慢了多少，但是這個結論其實還差很多，因為這兩邊差異可能來自：

Framework Runtime
        ↓
Scripting

Browser Rendering
        ↓
Layout / Paint

Application Code
        ↓
User JavaScript

Measurement
        ↓
Trace window / scheduling / observation timing

所以正式 Validation 是拆成三層：

Layer 1：結果有沒有變？ → Render Duration

Layer 2：成本發生在哪裡？ → Cost Trace

Layer 3：Framework 是否真的參與改善？ → Runtime Attribution

這三層必須一起看。

第一層：Render Duration 有沒有改善？

先看 Update。

乍看之下，N=100、500、1000 都是下降，如果今天只做到這裡，很容易判斷 Vue 3.6 在 Update Path 有改善，但是 N=5000 已經變成 +7.2%。

更重要的是，Render Duration 的方向一致，並不代表改善來源已經被確認。

第二層：到底是哪種 Cost 發生變化？

Cost Trace 把一次 Render 拆成幾個區域：

                    Render
                       │
        ┌──────────────┼──────────────┐
        ↓              ↓              ↓
    Scripting       Rendering      Painting
                       │
              ┌────────┼────────┐
              ↓        ↓        ↓
          Recalculate  Layout   Paint
             Style

Update 的結果很有意思。

按照表格數據發現 Scripting 小到中型 Node Count 的 Scripting 有下降趨勢，但是 Scripting 不等於 Vue Runtime ，因為 Scripting 裡面可能包含：

• Scenario 自己執行的 JavaScript
• Application code
• Vue Runtime
• V8 execution

所以第三層還是必要的。

第三層：Vue Runtime 到底有沒有變快？

這就是 Runtime Attribution 存在的原因，把 CPU Cost 再拆一次：

Scripting
    │
    └── CPU Attribution
          │
          ├── Vue Runtime
          ├── Application
          └── V8 / native

Update 結果裡，有三個 cell 通過目前設定的 Consistent Improvement 條件：

Vue Runtime CPU
N=500       −63.8%   10/10

V8 / native CPU
N=100       −46.5%   10/10
N=500       −61.0%   10/10

這裡第一次出現值得深入調查的訊號，尤其是 Vue Runtime CPU，N=500，−63.8%，10/10 paired direction。

如果只看到這裡，似乎已經可以說 Vue 3.6 的 Runtime 變快，不過 Attribution 本身也可能受到 trace window 的影響，所以還是要繼續做驗證。

為什麼還不能直接下結論？

把 N=500 的資料再往下拆，CPU profiler 10 個 trial 的總取樣時間：

Vue 3.5.40
2,765,479 µs

Vue 3.6.0-rc.2
1,040,065 µs

↓ 約 62%

這確實很接近 Vue Runtime CPU 的下降幅度，看起來像是一個真訊號。

但另一個數字很奇怪，取樣次數反而增加，而 Application CPU 幾乎沒有變。

這和 Mount N=100 / N=5000 的異常狀況不同，Mount 的數據表現是幾乎所有 bucket 同時膨脹，唯獨 Update N=500 沒有這種現象，所以 N=500 的 CPU attribution 有可能是真訊號。

Render Duration 與 Attribution 對不起來

同一個 Update N=500：

Render Duration

Vue 3.5.40      2.1 ms
Vue 3.6.0-rc.2  2.0 ms

Δ = −4.8%

可是，

Vue Runtime CPU

Δ = −63.8%

兩個數字的幅度完全不同。

如果 Framework Runtime 真的少了 60% 的 CPU 工作，為什麼 Scenario 最終量到的 Render Duration 只少了 4.8%？

目前這份資料沒有足夠證據解釋這個差距，只能推敲比較正確的判斷是：

Vue Runtime CPU −63.8%
        ↓
Consistent Improvement
        ↓
值得調查
        ↓
Render Duration 只有 −4.8%
        ↓
兩者幅度不一致
        ↓
尚不能確認 Framework Improvement

這裡就是 Attribution Validation 和單純 Benchmark 最大的差別。

第四層：先排除 Measurement Artifact

這次量測過程中，其實已經抓到另一個非常明顯的例子。

Mount N=100 / N=5000

Vue 3.6 相對 Vue 3.5 在其中 N=100 與 N=5000 的多個 metric 同時大幅膨脹，但是 N=500 與 N=1000 並沒有出現相同現象，這種 pattern 很難直接解釋成某個 Vue Runtime 改動造成！

因此這些 cell 被標記為 measurement artifact，不納入 Vue 3.6 regression 結論。

可見一個結果看起來很漂亮，仍然需要確認它是不是測量系統本身造成的，這也是為什麼這次 Validation 不只留下 benchmark number，還保留完整 trace。

Vue 3.6 有值得注意的訊號嗎？

本 Scenario、本 Node Scale、本次 measurement pipeline 下，沒有確認 Vue 3.6.0-rc.2 存在可重現、且能可靠歸因於 Framework 的效能改善。

沒有改善但是還是有值得注意的訊息，只是前只能稱為 candidate signal。

Candidate 01：Mount N=500 / N=1000

Browser Rendering 類指標多次朝 Vue 3.6 方向：

Rendering
Layout
Painting
Paint

多個 metric × node count 都有 7–9/10 的 paired direction，但 IQR 仍有重疊。

所以值得後續增加樣本驗證，還不能列為 confirmed improvement。

Candidate 02：Update N=500

Vue Runtime CPU       −63.8%
V8 / native CPU       −61.0%

而且 paired direction 都達到 10/10，但：

CPU Attribution       −60%+
Render Duration       −4.8%

兩者幅度差距太大，所以這是一個需要進一步調查的 Framework attribution candidate。

小結

Vue 3.6 到底改善了哪一個 Cost？

在目前這個 VDOM Stress Test、本次 Node Scale 與 measurement pipeline 下：

我們看到了幾個 Improvement Candidate，但沒有一個完成從 Render Duration → Cost → Attribution → Artifact Check 的完整證據鏈，被確認為 Vue 3.6 的可重現改善。

如果 Vue 3.6 的 Framework contribution 在這個 Scenario 裡沒有被確認，那麼當 UI Scale 繼續放大時，真正持續增加的成本到底在哪裡？

Day 20 接著回到這個問題：當 Framework Improvement 沒有被確認，剩下的 Rendering Cost 是什麼結構？